The documentation explains what has been discovered since the creation of a tool to decompress Entities.ebp, and the subsequent discovery that it is the fabled "Statistics Table," allowing for all sorts of numerical hacks. All values are "little endian." That is to say, to determine the value shown, you must first flip the order of the bytes (e.g. DE 01 -> 1DE), and then convert from hexadecimal to decimal. This is, of course, unnecessary for one-byte values (such as unit type). Conveniently, the 160-odd units in this game come right at the beginning. Each unit's data is 121 bytes long, e.g from 0x04 to 0x7C is the King. That sounds intimidating, but fortunately both sides of each block (except for the beginning of the King's) is bounded by A2 A2 A2, or the very recognizable ¢¢¢ in text. As I like to put it, the data goes "from c to shining c." It is important to note that the order of the units is not the same as the shop. It follows the order of sprites/models in the plaintext block at the bottom on the file. Basically, it goes: - King units - King buildings - Wizard units - Wizard buildings - Pirate units - Pirate buildings - Imperial units - Imperial buildings - Astronaut units - Astronaut buildings - Alien units - Alien buildings - Space Police - Space Criminals - Islanders - Ninjas - Dwarves - Trolls - Extra Heroes A majority of the data in each block has been either figured out, or determined to be useless filler. Let's go in order: Bytes 1 and 2 represents the long "card" seen in the shop and multiplayer/freeplay army select. Bytes 5 and 6 are the unit's ID. Changing this will make a unit vanish from Freplay/Multiplayer, and in the campaign they will take on the icon of the unit whose ID was used, along with their model if both units are 3D models. There also appear to be issues where, for example, making the King's ID the same as the Builders will cause the actual Builders in the level to not spawn. All in all, you really should not be touching this. Bytes 7 and 8 tell you what name the unit has. Again, it just increments up, this isn't all that helpful unless you need to do some name-length rearranging. Byte 10 tells you what macro-category a unit is, presumbaly based on their graphics: 00 is Hero, 01 is builder, 02 is special and transport, 03 is all the towers, and 04 is the other buildings. If you change types in a way that would switch between these without changing this value, the unit disappears (from Freeplay unit selection), but if you change both things, the game actually crashes when you start a match. Bytes 13 and 14 (right after the first ¢¢) are the unit's speed. The values don't seem to make all that much sense, we have: - 0x0155 = 341 = 1 star - 0x0177 = 375 = 2 stars - 0x019A = 410 = 2 stars - 0x01BC = 444 = 2 stars - 0x01DE = 478 = 3 stars - 0x0222 = 546 = 3 stars - 0x0266 = 614 = 3 stars - 0x02AB = 683 = 4 stars - 0x0333 = 819 = 5 stars - 0x0355 = 853 = 5 stars Along with a couple of weird values from strange units with 0 build cost that I can't prove the star-level of: - 0x0111 = 273 = 1 star? - 0x03BC = 956 = 5 stars? Bytes 15 and 16 are always 00 00 for non-buildings, and FF FF for buildings (including towers). This does not seem to do anything at all. Bytes 19 and 20 are exactly like this as well. Bytes 17 and 18 are FF FF for all buildings, 00 C0 for the vast majority of units, and 55 05 for the following units: Ballista, Catapult, Siege Tower, Barracuda, [P] Battleship, Clipper, Claw Tank, Starfighter, and Alien Attack Ship. The purpose of these bytes is unknown, and changing them has no obvious effect. Byte 21 seems to relate to having graphics appear near something, e.g. the Golden Minikit you see when building. Curiously, changing this seems to invalidate entire mechanical processes--for example, changing a castle from 07 means that you can queue up builders, but they will not build at all. Here is a table for these: - 00: Nothing (Lumber Mills, Farms, Bridges, and Gates) - 01: UNUSED - 02: Builders (no idea what this does) - 03: Heroes, infantry, and calvary (no idea what this does) - 04: Towers, ranged units, and for some odd reason Troll Giant (no idea what this does) - 05: Specials of all tiers (no idea what this does) - 06: Transport Ships (no idea what this does) - 07: Castles/HQs, Barracks, and both types of Special Makers (golden minifig) - 08: Mines (sparkles when you get money) - 09: UNUSED - 0A: Wall (smoke?) - Other/FF types have FF here It is probably a good idea to keep these in line with types, even if they mostly do not seem to do anything. Byte 22 seems to do nothing if changed, is next to a value which mostly does nothing, and has a distribution which has just enough irregularities to be unhelpful. As such, I am declaring this value to be useless, but providing a file in this repo named "byte22.txt" which shows you its amount for all units, in the hope that someone else can discern a meaningful pattern. Bytes 23 to 29 are a serious of related "flag" values (i.e. they are all either 00 or 01, off or on). Byte 23 is 00 for water-only units and Shipyards, and 01 for everything else; all it seems to do is turn a water-only unit into a land-only unit if you don't set it to 00 properly. Byte 24 is whether a unit can walk on land, and Byte 25 is whether a unit can walk on water. Bytes 26 is whether a unit can cross over trees, Byte 27 is whether a unit has collision with buildings, and Byte 28 is whether a unit can cross from land to water and back. Do note that, strangely, you need Byte 27 off and Byte 28 on to cross, but Byte 27 works fine all by itself. Finally, Byte 29 is 01 for bridges and whatever Gates are, and 00 for everything else; turning it to 00 for a bridge renders the bridge invisible (but stil able to be walked over). Byte 30 represents the size of a unit's collision box (which is also their hurtbox and hitbox). Seeing as Towers and normal sprite units are both a 1, one must assume this value is relative to the size of their sprite. Bytes 31 and 32 represent the size of the sprite in 8x8 tiles. Byte 31 is Width, and Byte 32 is Height. Obviously, you should not change these unless you resize the sprites in question, or else graphical glitches will occur. Also, these bytes are 00 00 for specials, since they are 3D models. Byte 33 is 00 for all units, and only matters for buildings because they are all part of one giant sprite. This value tells you what tile in that sprite to start from, at which point the appropriate number of rows and columns from above is draw. As you can see in NitroPaint, this value is based on the top-left tile of the building. Byte 34 is 01 for buildings such as Stonehenge which have no health and cannot be interacted with in any way, and 00 for everything else. Bytes 37 and 38 (the ones right after the second ¢¢) tell the game what wallking/attacking sprite set to use. The values between units seem nearly random, so you're better off just replacing the graphics themselves. Bytes 41 to 46 are unusual in that they are all 00's for most units, and then a specific, consistent set of values for the following: - For Castles, they are 01 02 00 02 00 01 - For Lumber Mills, they are 00 02 00 00 00 01 - For Transport Ships, they are 01 04 04 04 02 00 Thus, one would conclude that it has something to do with units being able to "go into" these entities. However, editing these values does absolutely nothing, and since (for example) whether a transport ship can transport things is based on its Type, I suspect that this is the remnants of some earlier scheme for assigning what does what. Then we have something of a long interlude of useless bytes, much of which are 00 unless you're a transport ship or building (here we can note that the many values inapplicable to buildings are listed as FF). Finally, the 93rd byte, the dot between i..¢¢ and i, is the Type of the unit. It goes mostly in order; see the list below. Please note that if you assign 05/06 to a sprite unit, or the others to a model unit, the thing will just not show up. Also, whereas changing the sprite types actually changes the unit, it seems the members of the various tiers of specialness are hardcoded by location, and that the transport type thus only determines whether people can actually board/disembark the vehicle. And now here's the type list: - 00: Hero - 01: Builders - 02: Melee - 03: Ranged - 04: Mounted - 05: Transport - 06: Special - 07: Castle - 08: Lumber Mill - 09: Mine - 0A: Farm - 0B: Barracks - 0C: Special Factory - 0D: Tower 1 - 0E: Tower 2 - 0F: Tower 3 - 10: Shipyard - 11: Bridge - 12: Gate - 13: Wall - FF: Other After this, we quickly get to the good stuff, right in order. Starting from byte 95 comes: - two bytes of build cost - two bytes of build time (this has been proven to be in frames, at 30 FPS) - two bytes of health - two bytes of mana (or 00 00 for non-heroes) - two bytes of what projectile they use (or FF FF for non-projectile-users) - four bytes of attack (the first two are the lower bound, and the second two are the size of the range, i.e. upper bound = first two + second two) The attack stat is 00 00 00 00 for projectile-users, because damage is defined on a per-projectile basis (see below). Byte 109 is 00 for so many units that I thought it was filler, but apparently it controls how much money the mine gives you. Do not set this above 99 aka 0x63, or the money display will take too long to increase and everything will run together and it's a mess. Byte 110 represents the wait time between attacks. One must assume this is also in frames (at 30 FPS), especially since the value for (non-Tower) buildings is always 1E, i.e. 30. Byte 112 represents a unit's range. It is always 01 for melee units and buildings. The values for this are not well understood, other than that they are some sort of index, and not an actual distance amount. So just base things of the ranges of vanilla units. Byte 113 represents how much the unit is prioritized when the AI chooses what to attack. The values themselves are essentially meaningless, it's all based on the relative values of each unit nearby. Higher-value units are prioritized over lower-value units. Byte 114 represents how much fog a unit dispels. Again, the exact sizing of these values is unknown, other than that FF clears the whole map. So just copy values of other units for this. Finally, bytes 115 to 119 represent the powers of the unit. These are, of course, all 00 for non-heroes. Otherwise, we have a nifty chart, presented here after a fair amount of busywork: POWER TABLE: 00 = NO POWER 01 = Unit Heal (UNUSED, costs 100) 02 = Unit Heal (UNUSED, costs 100, presumably exactly the same as 01) 03 = NONE 04 = Unit Speed Boost (UNUSED, costs 100) 05 = Area Speed Boost 06 = Unit Damage Boost (UNUSED, costs 100) 07 = Area Damage Boost 08 = Unit Armor Boost (UNUSED, costs 100) 09 = Area Armor Boost --Note that the area boosts and unused unit boosts cost exactly the same-- 0A = Forest Spawn 0B = Crystal Cache 0C = Jungle Growth 0D = Earthquake 0E = Fireball 0F = Lightning 10 = Thunder Hammer 11 = Mining Buff 12 = Roar 13 = Logging Buff 14 = Monkey Swarm 15 = Crab Swarm 16 = Coconut Storm 17 = Artillery 18 = Trade Winds (UNUSED, costs 500, I can't really tell what it does other than make the leader go faster) 19 = Arrow Volley 1A = Teleport 1B = EMP 1C = Space Laser 1D = ESP 1E = Tracking 1F = Cluster Bomb 20 = Hot Wire 21 = Unit Heal (UNUSED, costs 500, presumably heals more than the others) After this come two bytes that are 04 02 for all towers, 00 00 for all other non-hero units, and 01 05 for *almost* all heroes. Why some (Brickbeard, Lady Pirate, Broadside, Camila, Biff, Gemma, Alien Commander, and Alien Queen, specifically) also have 00 00 here is entirely unknown. It is currently recommended to stick with whatever is there in vanilla unless something is not working right. In order for the byte numbers to work out right, technically the ¢¢¢ after a block must be counted as part of that block. Then you start the next one right after it, and everything is just like it would be if you looked at the King. The last unit is Santa, and his block ends at 0x5828. Then there is the data for 27 projectiles, which ends around 0x6420. Then there are 30 random map sprites (the cargo pods etc.), and that ends around 0x71B7. Then we have the 30 freeplay maps. With the projectiles, I can't really make a declaration on where blocks truly begin and end. However, 0x5830 has the first projectile's ID, and then every 116 bytes after that is the next ID, so that's as good a place to deliminate as any. Said ID's conveniently match up with what is found in the ranged units' data. The damage of a projectile is found at the 17th to the 24th bytes after a ¢¢ÿ group, those being in turn the 85th byte after the ID. It is notable for being duplicated for no good reason. It is also a range, with the 17th-18th and 21st-22nd bytes both showing the minimum value, and the 19th-20th and 23rd-24th showing the maximum value. The first freeplay map starts at 0x71E0. You can tell because the fifth byte after that is 05, not 03 or 04. The last/30th map starts at 0x7E90. Unlike units, freeplay maps are nice and neat, and cleanly live between ...i...i groups. The 21st byte from the start of a map group (i.e. The One After the FF) is the map's ID. Map IDs can be for some reason be used any number of times. Thus, my hack to start with all maps unlocked literally just changed all their IDs to 00. After the maps are a bunch of similar looking groups, whose fifth byte is 04. This continues up to the group starting at 0x9BE0. That group's fifth byte is 02, until we get to the group starting at 0xA510, when the fifth byte switches to 0B. The group starting at 0xCA40 has a fifth byte of 07, and that keeps going for a relatively short time to 0xD220, at which point it becomes 09. All the way down at 0xF980 there is a single fifth-byte-08 block, then a tiny fifth-byte-03 block, and we're at the plaintext chunk. Based on the text in the chunk, I can pretty confidently say that 04 is Concept Art, 02 is Hints, 0B is Minifigs, 07 is Red Bricks, 09 is Minikits, 08 is something called a "Ticket," and the 03 is the scroll from King level 1-3, which for some reason is all the way down here and not with the other 03's that come before the freeplay maps. HOW TO ACTUALLY EDIT ALL THIS STUFF: 1. Legally back up your LEGO Battles cartridge, yielding a .nds ROM file 2. Download CrystalTile2 (https://www.romhacking.net/utilities/818/) 3. Use it to extract the files from the ROM (i.e. load it, go to Tools -> NDS File System, and inside that window do File -> Split Rom) 4. Download the Decompressor Thing, hacked into being by yours truly (https://github.com/opiter09/Hacky-LZ11-Container-De-Compressor) 5. Drag and Drop the file BP / Entities.ebp you got from the ROM onto our decompressor 6. You will see an empty window, just close it. Now you have a testD.bin 7. Open that up in a Hex Editor, do whatever you want to it 8. When you want to put it back into the ROM, first compress it by dragging it onto HackedNitroPaint.exe again. This will again give you a window to close, and the file testC.bin 9. Rename testC.bin to Entities.ebp, then open CrystalTile2 again 10. Load your ROM into it, go to File -> NDS File System. For convenience, click View a list of -> Directory to show files inside folders instead of in one gigantic list. Then scroll down to BP -> Entities.ebp 11. Left click the file to select it, then right click, press Import, and choose your edited file 12. Now save the ROM. CrystalTile2 is weird, so you have to save by trying to quit and then clicking No to cancel. Then quit for real to be done CREDITS Because more thanks are never bad, I, OEA, would like to take the opportunity to once again thank Garhoogin, the creator of NitroPaint. It was their willingness to look into why LEGO Battles images were not loading into that program, and then to reverse engineer the compression method used by this game in order to fix that, that allowed all the hacks for LEGO Battles, and this documentation, to exist at all. I hope Garhoogin is happy knowing that they singlehandedly created a romhacking scene where there was none before.